Business Analyst Community & Resources | Modern Analyst

Spring Cleaning Your Personal Backlog

Jarett Hailes — Sun, 18 Apr 2010 04:44:00 GMT

As spring begins to plant its roots in the Northern Hemisphere, many people will begin an annual spring cleaning of their home. All the clutter that has accumulated over the past 3, 6, 9, or even 12 months since the last cleaning is collected, assessed and then dealt with (either by moving stuff to a better location, actually using the thing, or throwing it away/selling it).

Like our homes, most of us have a bunch of ‘to do’s’ that build up over time. Whether you are someone who meticulously manages all the tasks that you must do or you are someone who will try and keep all their ongoing duties solely in your head, chances are that you have a list of things that you have wanted or needed to do but have never quite found the time to get around to. I like to call the list of outstanding tasks that someone has to do (whatever their context; personal or work-related) a personal backlog.

While there’s nothing wrong with not crossing off all your tasks (after all, who really has time to do everything they need or want to?); over time you can develop a level of ‘accountability debt’ to yourself. Most active and high-achieving people strive to get as much done as possible, and when they can’t complete everything that everyone has asked of them they usually take it personally, either at a conscious or unconscious level. This could be manifested as internal guilt, frustration, stress or other negative emotions.

As you feel bad about not being able to accomplish everything you start to make more and more mental reminders of all the things that you haven’t been able to do as if this action itself will help get more tasks completed. This action simply clutters up your brain, which has a finite amount of space for keeping track of things. As your personal backlog list continues to grow, you end up crowding out more pertinent or relevant information from your mind. This can lead to feelings of confusion or lack of focus on the tasks at hand that matter the most.

So, if you’re feeling like you have a million things on your mind, it’s time to perform a little spring cleaning. This activity will involve 4 steps as described below.

Collect

Write down everything you can think of that someone has asked you to do or that you’ve pledged to do. Nothing is too big or too trivial to be included in this list. This should span your work and personal lives; don’t forget about promising to clean Aunt Martha’s eaves troughs (you know she won’t). Include problems that you need to solve (for instance, figuring out how to make your sales estimates more accurate going forward or what to do about your son’s late nights) and that you may need some dedicated thinking time to properly ponder.

This may not be something you can do in one session, but allocate some dedicated distraction-free time to this effort. You will be surprised how many little items come bubbling back to the surface once you get on a roll.

If you already have one or more to do/task lists, this is a great place to start. For this activity you will want to consolidate all of your task lists into one big master list. You may be used to segregating certain aspects of your life and find it effective to manage them that way, but from a spring cleaning perspective you will need to look at everything holistically.

Don’t be surprised (or daunted) if this list grows into hundreds of items; instead take satisfaction that you now have a single point of reference for all your outstanding action items. You no longer need to carry these about in your brain’s short-term memory.

Break Down/Up

You will want to review your list for items that are not immediately actionable (that is, there is something that you would first need to do in order to accomplish the stated item). Those items should be moved to a second reference list and be linked in some way to the one item that is currently actionable on the main list.

This way your to do list becomes a series of ‘next action’ steps, not some nebulous list of end goals that may have dozens of steps that need to be performed in order to be accomplished. Having a list for achievable next steps will add value to this list when you’re looking for what you should do next or at a given moment.

Prioritize

Once you have your master list, it’s time to prioritize. The goal of this prioritization is to have a single ordered list from the highest priority item to the least priority item.

Some of you may want to categorize your items into work and life at this point. I personally find that my life is not so easily segregated (and I would suspect that with modern working practices most people’s are not either), so I would suggest you try and come up with a single prioritized list.

Similarly, you may have a desire to have ‘high/medium/low’ or similar buckets and then just place all your tasks into one of the priorities. While this may be a good starting point so you can manage prioritizing elements further, having buckets of items doesn’t help you actually get any of the tasks done later on. When you’re in working mode, you will want to quickly scan the top of the list and see which of the items are actionable at the moment. Having a list of 10-30 ‘high priority’ items doesn’t help you make a decision at that point, and can lead to feeling overwhelmed and helpless right at a time when you could be easily getting started to work on something.

If you need help getting started, associate due dates to the items that jump out at you off the page as stuff that has to be done by a certain time. This should help you figure out where some of the items fit on the list. Others may not have a set due date but still need to be placed higher up the list.

The end product doesn’t have to be perfectly prioritized; you shouldn’t spend more than a few seconds debating whether one item is above or below another. The goal is to have a general order of importance based on your current life situation that can be easily referred to going forward.

Prune

Once you’ve prioritized your list, start scanning the items from top to bottom. After each item ask yourself “do I really need to get this done?” Once you start running into a steady sequence of ‘no’ answers, start looking for a place to cut off the list and remove all the items below it. Then quickly scan the remainder of the items to see if there’s anything you actually do need to do and bring it back to the pruned list (or perhaps add a couple of items to your pruned list for ‘Sorry I can’t do this messages’).

You need to be honest with yourself and look at your available time, your other commitments and obligations and your personal energy levels and goals to figure out where the line should be drawn. But you do need to draw the line somewhere; I haven’t met anyone who is able to accomplish everything that they put down when they’ve done a brain dump.

Ongoing Maintenance

Once you’ve done this activity, you now have an actionable, up to date and realistic list that you can use going forward to take on your tasks and duties. If you use this opportunity to manage this list on an ongoing basis, you will likely find that your mind will be less cluttered and you will be able to easily find tasks that you can do in any given situation (e.g. those 10 minutes between your meetings) by keeping this list up-to-date and close at hand.

Spring cleaning can feel like a chore, but when you do it on your personal backlog the benefits of a clearer mind and the ability to focus easier without worrying about forgetting to do something can be a major energizer for the months ahead.

Mitigating the Risk of Story Point Drift

Jarett Hailes — Mon, 18 Jan 2010 01:38:00 GMT

In many Agile projects requirements are not typically written in the form of a formal requirements document. Instead, a collection of concise but effective means of describing what must be built called user stories are often used. User stories describe the behaviour, performance, or interface of a system from a customer’s perspective. A typical user story might look something like this:

As a potential customer I want to be able to view books based on the search criteria I entered.

User stories are not only effective requirements management artifacts, they are also essential to estimate the scope/size of the project and to track the progress of the team. When determining the size of the project, teams estimate the level of effort required to complete each user story and then aggregate their results to come up with their estimate for the scope of the project (for more details on how to estimate level of effort in Agile projects, see Mike Cohn’s excellent book on the subject).

Agile teams will often use a unit-free type of measure called story points. The advantage of using story points is that their inherent value is relative. Instead of trying to come up with absolute values typically related to time (for instance, how many days will it take to complete feature X), story points are only concerned about the relative effort or complexity of a story compared to the other stories that have been or need to be completed. When the total number of story points for the project is combined with a team’s velocity (the number of story points completed per iteration period) project stakeholders are able to get an increasingly accurate picture of the size of the project and the time it will take to complete given the current team.

Initially when the team forms they will estimate story points for some number of baseline stories. For instance, the team may have the following 3 stories as their baseline:

As a user I want to browse the book collection by subject: 8 points

As a user I want to be able to save my payment information: 2 points

As a user I want to be able to recommend my favorite books to people: 5 points

From this baseline other user stories are estimated in terms of their perceived relative amount of effort to accomplish. For larger projects, most user stories are estimated as epics, larger user stories that will be broken down later on in order to actually tackle development.

Over time, new user stories will be added to the product backlog, others removed and some will be altered to reflect changing requirements. All the stories that are added or changed to the backlog will require story point estimation.

One of the potential risks that exists when using story points is what I call ‘story point drift’. Story point drift is when user stories that had a given story point value at the beginning of the project require substantially more or less effort than stories with the same story point value later on in the project for the given amount of effort required to complete a story.

For instance, let’s say I have the following user stories estimated later in the project:

As a user I want to be able to have my bank account linked to my login and set up a monthly withdrawal plan: 8 points

As a user I want to have a theme editor that can customize the look and feel of my online affiliate store: 5 points

While the above user stories may accurately represent their relative size compared to each other, in comparison to the stories that were estimated at the onset of the project it appears as though the latter group’s story points under-represent their complexity and level of effort required. I would suspect that the amount of work to enable automatic bank transactions is substantially larger than the amount of effort required to build a browse by subject feature.

I find the risk of story point drift increases on larger or longer-term Agile projects. Story point drift can occur for several reasons:

The team’s collective memory is short term: when a team begins estimating new stories, they typically draw upon their experiences from recently completed stories. If some of those stories were misclassified (either required materially more or less relative effort than was represented in the story point estimate), then the team can end up believing that these recent stories are the new norm for the value of the story points and use these as references going forward, which skew the story point values from the original baseline references.

The team’s complement has changed: it is not uncommon for project teams to change over time. I’ve noticed that even as teams get larger or smaller that a team’s velocity can appear to remain constant. When investigating this, I’ve found that it’s often because the team begins to estimate stories with fewer points, since they now feel that the story is ‘easier’ since there are more people to work on the project. As a result stories that might have been considered 8 points previously are now being estimated as 5 points. As a result, despite the fact that the team is likely getting more done given their drift in estimates the team’s velocity appears unchanged.

Baselines are not referred to: Agile projects usually thrive by the minimization of overhead that does not lead to customer value and by adapting to non-ideal situations. For example, Agile teams rarely wait for everyone to show up for a meeting – the meeting is time-boxed and starts and ends on time regardless of who is missing. However, at times Agile teams may forget to bring physical objects like their reference stories to meetings. Sometimes teams will try and get through the meeting based on recollection rather than actual reference. Without the actual reference stories and point values in hand, the resulting estimates can be somewhat skewed.

When I’ve seen story point drift it has occurred in small increments over time – you don’t realize that there’s been a dramatic deviation in the estimates until sometimes months later. Story point drift can cause issues with resource planning and progress and time to completion estimation. Here are a couple of strategies I’ve used to help mitigate story point drift:

Bring mixture of original and recent stories as the baseline for new estimation: it never hurts to hold up your original estimates when doing relative comparisons. Having some recent examples are also helpful, in particular since your initial estimates were likely only for a few potential story point values. Having 1 or 2 stories for each possible story point value can also be helpful when discussing what level of estimate to assign to a new story, or when individuals are deadlocked in a session of planning poker.

Know when certain stories should be re-estimated after implementation: once in awhile you will encounter a story that was a lot more (or less) effort than you initially thought. If the level of effort was sufficiently different from another story that was given the same amount of points, you may want to re-estimate the story so that it does not affect your team’s perception of the value of a certain number of story points. I typically would only re-estimate a story once a project has been going for several Sprints – early on you may discover that many of your stories take less or more effort than you thought and you’ll be tempted to resize those stories. However, as long as the stories are taking about the same amount of relative effort, then there’s no need to re-estimate. So if you thought your 3 point stories would take a day to complete but they’re taking the better part of a week, check to see how your 5 and 8 point stories are taking. If those are also taking a fair bit longer than anticipated, then don’t re-estimate.

Spend a little time every few Sprints and analyze relative stories: the ScrumMaster or Project Manager can review some of the completed stories over time to look for possible story point drift. If some drift is detected, bring it up with the team and see what they think. If the team agrees, then re-estimate the stories that appear to be out of what in terms of relative effort.

User stories and story points can be a very good way to manage the requirements and estimation for a project. Keeping an eye on story point drift will ensure that the team has a good handle on the project’s rate of progress and estimated time to completion. With diligence this method of project estimation can be a very accurate and effective tool for Agile teams.

-------

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Dispatches from the WCBA Conference: Retrospectives

Adrian M. — Wed, 18 Nov 2009 18:51:00 GMT

Dispatches from the WCBA Conference: Retrospectives

“Slow Down to Speed Up: Retrospectives for Improving Product and Process” was the title of one of the workshops I attended during day two of the WCBA conference.

Ellen Gottesdiener, Founder and Principal Consultant, of EBG Consulting tackled the subject of “Retrospectives”.

It was a great presentation and included a number of topics including:

What are Retrospectives?

“Retrospective – a ritual in which the entire project community comes together: reviews the iteration/release/project story (something which just finished), harvests the collective wisdom of the teams, tells the truth without blame or judgment, identifies what to appreciate and improve, understands and forgives its failings, and relishes in its successes.”

In a nutshell, it’s our chance to look back in the rear view mirror and learn from what just took place. The insights gained from retrospectives become the basis for improvement, both immediate and longer term.

Careful using terms such as postmortem (are you assuming you project is dead?)…

In order for a retrospective session to provide value, it must address 5 key questions:

· What did we do well that we might forget if we don’t discuss it soon?

· What did we learn?

· What should we do different next time?

· What still puzzles and intrigues us?

· What needs more in depth discussion and analysis?

When should Retrospectives take place?

The traditional practice for doing retrospectives or postmortems (if your project is dead projects) is at the end of the project. The problem with this approach is that on projects with longer duration the value and benefit of the retrospective diminishes as it is far removed from when most of the project activities took place.

Alternately, retrospectives can be done sooner than the end. For projects which have a set rhythm (regular iterations, regular releases, etc.) a retrospective session can be done at after of each of the repeating phases.

Lastly, you should also consider an ad-hoc retrospective as a valuable tool when you get caught by surprise by a project challenge or other significant unplanned event in the life of the project.

Why Retrospectives?

As with everything else that we do, retrospective must provide value in order to be worth the time and energy. Ellen explored the value proposition of this tool.

In a nutshell, retrospectives are a great way to harvest the collective wisdom of the entire project team by giving everybody a chance to tell the story from their perspective and to discover things that happened on the project that you did not know about.

Retrospective is a great method of free adaptive learning:

· Immediacy – doing the retrospective as soon as possible ensures the recent experiences are sharp in the team’s memory,

· Relevance – the learning is relevant because the team has a common vested interest in the project/milestone/iteration/release what just completed,

· Self-Direction – most of us we don’t like to be told what to do ->retrospectives allows the individual contributors to identify and choose what they want to adapt and change going forward.

Retrospectives that Work

A retrospective is a great community participation-based tool which works because needed change is identified, proposed, and implemented by the project team and not simply shoved down their throats by some executive who is disconnected from the day to day realities of the project.

Successful retrospectives:

· Use data -> how many stories we implemented as opposed to the last iteration, how many test cases per story, how many defects per function point, etc.

· Acknowledge individual feelings -> Remember that feelings do count!

· Have a pre-defined structure –since everybody knows that it will take place, it provides the freedom to participants to identify and implement change without fear or guilt.

A good structure for your retrospective session looks like this:

1. Readying – set the stage

2. Past – gather data

3. Present – generate insights

4. Future – decide what to do

5. Retrospect – close the retrospective (retrospect the retrospective)

Retrospective = basis for change – it’s really a very cheap, yet effective, change management strategy